style="width:10.04028in;height:5.56042in" />
style="width:0.19336in;height:0.15994in" /> 本文是学习GB-T 34941-2017 信息技术服务 数字化营销服务 程序化营销技术要求. 而整理的学习笔记,分享出来希望更多人受益,如果存在侵权请及时联系我们
本标准规定了数字化营销中各程序化营销平台之间的接口，程序化营销执行过程的基本活动和任
务，以及程序化营销中涉及的各类数据的定义、来源、分类和应用。
本标准适用于各个广告交易(平台)与需求方平台之间的竞价和ID
映射，广告主资质和广告物料审
核，数据测量与计费，以及用户、媒体、广告主数据的分类及应用。
下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅注日期的版本适用于本文
件。凡是不注日期的引用文件，其最新版本(包括所有的修改单)适用于本文件。
GB/T 2260—2007 中华人民共和国行政区划代码
GB/T 4880.1—2005 语种名称代码 第1部分：2字母代码
GB/T 12406—2008 表示货币和资金的代码
下列术语和定义适用于本文件。
3.1
程序化营销 programmatic marketing
通过自动化程序和大数据技术实现广告主与媒体之间的广告交易的营销方式，包括实时竞价模式
和非实时竞价模式。
3.2
实时竞价 real time bidding
利用第三方技术在数以百万计的数字媒体上，针对每一个用户的广告展示进行评估，以及实时出价
的竞价技术。
3.3
广告交易(平台) advertising exchange(platform)
开放的、能够将 SSP 或媒体和DSP
联系在一起，提供广告数据交换、分析匹配和交易结算等服务的
在线广告交易平台。
3.4
需求方平台 demand side platform
整合广告主需求，为广告主提供发布服务的广告主服务平台。
3.5
供应方平台 supply side platform
整合媒介方资源，为媒介所有者或管理者提供程序化的广告分配和筛选的媒介服务平台。
GB/T 34941—2017
3.6
广告主资质 advertisers qualification
广告主投放广告具有的法律规定的必备资质，分为基本资质和特殊行业资质两类。
3.7
302重定向 302 redirect
302 暂时性转移 302 temporary redirect
当用户点击一个网址时，通过技术手段，跳转到指定的一个网站。
3.8
广告主数据 advertisers data
作为品牌商品的拥有者和营销推广者的广告主，在生产经营过程中所积累产生的相关数据。
3.9
应用程序 application
移动设备中可独立运行的程序。
3.10
数据管理平台 data management platform
帮助所有涉及程序化营销的各方，用于管理其数据的系统平台。
3.11
用户数据 user data
与用户身份或活动相关的数据，包括可用于识别出用户身份的个人信息，以及反映用户网络活动的
行为数据。
3.12
媒体数据 media data
以互联网媒体为主体，描述互联网媒体类型与媒体所属行业的分类数据。
下列缩略语适用于本文件。
Ad Exchange:广告交易(平台)(Advertising Exchange)
APP: 应用程序(Application)
CRM: 客户关系管理(Customer Relationship Management)
DMP: 数据管理平台(Data Management Platform)
DSP: 需求方平台(Demand Side Platform)
ERP: 企业资源计划(Enterprise Resource Planning)
FLV: 流媒体格式(Flash Video)
GIF: 图像互换格式(Graphics Interchange Format)
HTTP: 超文本传送协议(HyperText Transfer Protocol)
HMAC: 散列消息鉴别码(Hash-based Message Authentication Code)
ID:标识符(Identifier)
IP:因特网协议(Internet Protocol)
JPG: 联合图像专家组格式(Joint Photographic Experts Group)
JPEG: 联合图像专家组格式(Joint Photographic Experts Group)
GB/T 34941—2017
MIME: 多用途因特网邮件扩展类型(Multipurpose Internet Mail Extensions)
MP4: 动态图像专家组第四版格式(Moving Picture Experts Group 4)
MRAID: 移动富媒体广告接口定义(Mobile Rich Media Advertising Interface
Definitions)
Protobuf:协议缓冲区(Protocol Buffer)
PNG: 可移植网络图形格式(Portable Network Graphic Format)
QPS: 每秒查询率(Query Per Second)
RTB: 实时竞价(Real Time Bidding)
SHA: 安全散列算法(Secure Hash Algorithm)
SSL:安全套接层(Secure Sockets Layer)
SSP: 供应方平台(Supply Side Platform)
SWF:Flash 文件格式(Shock Wave Flash)
URL: 统一资源定位符(Uniform Resoure Locator)
VAST: 视频广告投放模板(Video Advertising Serving Template)
XHTML: 可扩展超文本置标语言(Extensible HyperText Markup Language)
XML: 可扩展置标语言(Fxtensihle Markup Language)
在程序化营销中，通常采用实时竞价模式完成营销过程。实时竞价是指在
SSP、Ad Exchange和多
个DSP 之间完成的实时竞价采买广告的过程，如图1所示。
style="width:10.04028in;height:5.56042in" />style="width:0.19336in;height:0.15994in" />
图 1 实时竞价流程
如图1所描述，用户访问包含广告的网页或者启动其他带有广告的应用程序，媒体或
SSP 将会发 起广告展现请求，Ad
Exchange收到该请求后，发出竞价请求给与之对接的多个DSP, 各个DSP 发出竞
价响应，Ad Exchange根据竞价规则将获胜的 DSP
的广告播放信息及广告胜出通知返回供媒体，媒体
在广告展现后向获胜的DSP 返回广告胜出通知。为了建立 Ad Exchange与 DSP
之间的标识符映射关
GB/T 34941—2017
系，Ad Exchange会在广告页面上发起标识符映射请求，将 Ad
Exchange方的用户标识符传递给 DSP。
图1流程中每个步骤即是本标准实时竞价协议需要定义的接口，说明如下：
a) 广告展现请求，此为 SSP 和 Ad Exchange间的接口，SSP 向 Ad Exchange
请求广告，本标准不 包含对此接口的规定；
b) 竞价请求，Ad Exchange和 DSP 之间的接口，Ad Exchange 向 DSP
发起竞价；
c) 竞价响应，Ad Exchange和 DSP 之间的接口，DSP 向 Ad
Exchange返回竞价；
d) 广告播放信息，Ad Exchange 和媒体之间的接口，Ad
Exchange返回广告给媒体，本标准不包 含对此接口的规定；
e) 广告胜出通知，媒体和DSP 之间的接口，媒体通知DSP 在竞价中胜出；
f) 标识符映射，Ad Exchange和 DSP 之间的接口，Ad Exchange和 DSP
进行标识符映射。
竞价请求、竞价响应、广告胜出通知和标识符映射环节的具体内容将在随后的章条中进行详细
规定。
在Ad Exchange与 DSP 之间的网络连接基本采用HTTP
协议，并且为了减少连接的处理时间，宜
开启长连接模式。由于 HTTP POST相比 HTTP GET
方式能更好地处理二进制数据，能传递更大数
据，要求发送竞价请求给 DSP 时采用HTTP POST方式。 DSP 与 Ad Exchange
之间的超时时间不应
超过200 ms。
在媒体/SSP 与 Ad Exchange之间的网络连接基本采用HTTP 协议，由 Ad
Exchange 提供广告对
应的请求链接地址，并返回对应的广告播放信息(包含 Ad Exchange 以及获胜 DSP
的广告胜出通知)。
服务器对服务器的连接，会带来额外的处理负担，不宜使用SSL
协议，也不宜在应用层协议中提供
额外的安全验证手段。服务器间通信的安全措施可由交易双方确定。
竞价请求与响应的应用层数据格式约定为Protobuf(一种高效数据交换协议),具体的字段描述见
5.2和5.3。请求和回复消息内容的 MIME 类型应填写为：
a) Content-Type:application/x-protobuf;
b) 广告播放信息数据格式采用超级文本标记语言(HTML)。
协议版本命名包括协议名称和版本号，名称定义为"x-dmss-pm-version",版本号分为主版本号和
次版本号两级，例如：1.2,主版本号和次版本号的变化都表示协议发生了实质改变。次版本号的变化需
要保证向后兼容，主版本的变化不需做到向旧版兼容。
竞价请求的应带上版本信息，以处理竞价请求的服务识别其版本和相应字段；竞价响应部分宜带上
系统当前支持的版本信息，例如：x-dmss-pm-version:1.0。
在程序化营销过程中，为满足广告主对于交易的需求，应支持下面四种交易模式：公开市场竞价、私
有市场竞价、程序化优选和程序化包断。这四种交易模式的示意如图2,模式说明见表1。
GB/T 34941—2017
style="width:12.07361in;height:7.00694in" />
图 2 多层级交易模式示意
表 1 多层级交易模式说明
|
|
|
|
|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
竞价请求按照Bid Request 协议格式封装请求数据，该数据包含 DSP
报价依赖的竞价基本信息(竞
价请求信息、广告位信息、创意信息)、受众信息(用户信息、设备信息、位置信息)以及展示环境信息(网
站信息、移动应用信息、视频信息),通过对象来封装。
竞价请求中各个对象的层级关系如图3。对象信息的描述和对应的章条见表2。
GB/T 34941—2017
Bid Request(竞价请求)
Impression(展现)
Creative(创意)
Preferred deals info(优先交易信息)
Preterred order(优先交易订单)
Guaranteed deals into(包断交易信息)
User(用户)
Device(设备)
Greo(位置)
Site(网站)
App(移动应用)
Vidco(视频)
图 3 竞价请求接口中对象的层级
表 2 对象和章条对应关系
|
|
|
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
竞价请求实现示例参见附录 A。
GB/T 34941—2017
5.2.2.1 竞价请求对象的定义
竞价请求对象定义见表3。
表 3 竞价请求对象的定义
|
|
|
|
|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
5.2.2.2 展现对象的定义
展现对象的定义见表4。
表 4 展现对象的定义
|
|
|
|
|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
23 — 视频后贴片；32位整数 |
|
|
|
|
|
|
|
|
|
GB/T 34941—2017
表 4 (续)
|
|
|
|
|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
5.2.2.3 创意对象的定义
创意对象的定义见表5。
表 5 创意对象的定义
|
|
|
|
|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
5.2.2.4 用户对象的定义
用户对象的定义见表6。
表 6 用户对象的定义
|
|
|
|
|---|---|---|---|
|
|
|
|
GB/T 34941—2017
表 6 (续)
|
|
|
|
|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
5.2.2.5 设备对象定义
设备对象的定义见表7。
表 7 设备对象的定义
|
|
|
|
|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
GB/T 34941—2017
表 7 (续)
|
|
|
|
|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
5.2.2.6 位置对象定义
位置对象的定义见表8。
表 8 位置对象的定义
|
|
|
|
|---|---|---|---|
|
|
|
|
|
|
|
|
5.2.2.7 网站对象定义
网站对象的定义见表9。
表 9 网站对象的定义
|
|
|
|
|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
style="width:0.53336in;height:0.53328in" />class="anchor">GB/T 34941—2017
表9(续)
|
|
|
|
|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
5.2.2.8 移动应用对象的定义
移动应用对象的定义见表10。
表10 移动应用对象的定义
|
|
|
|
|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
5.2.2.9 视频对象的定义
视频对象的定义见表11。
表11 视频对象的定义
|
|
|
|
|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
5.2.2.10 优先交易信息对象的定义
优先交易信息对象的定义见表12。
GB/T 34941—2017
表12 优先交易信息对象的定义
|
|
|
|
|---|---|---|---|
|
|
|
|
|
|
|
|
优先交易订单对象的定义见表13。
表13 优先交易订单对象的定义
|
|
|
|
|---|---|---|---|
|
|
|
|
|
|
|
|
5.2.2.11 包断交易信息对象的定义
包断交易信息对象的定义见表14。
表14 包断交易信息对象的定义
|
|
|
|
|---|---|---|---|
|
|
|
|
|
|
|
|
DSP 在接到 Ad Exchange 的竞价请求以后，无论是否参与竞价，都应在 Ad
Exchange 规定的时间 (不宜超过200 ms) 内处理请求，向 Ad
Exchange发送竞价响应。在规定的时间内，Ad Exchange 没有
收到或者无法解析 DSP
的竞价响应，则广告交易平台视这次竞价为错误。对于竞价错误率较高的
DSP, 广告交易平台将可对其发送给DSP 的流量作出限制。
竞价响应按照Bid
Response协议格式封装请求数据，该数据包含对展现机会的出价和广告创意信
息。如果 DSP 不参与竞价，则需要把所有字段留空，并把 HTTP
状态码设成204。
竞价响应的大小不应该超过32千字节。
竞价响应接口中对象的层级见图4。对象的描述和对应的章条见表15。
GB/T 34941—2017
|
|---|
图 4 竞价响应接口中对象的层级
表15 对象和章条的对应关系
|
|
|
|---|---|---|
|
|
|
|
|
|
|
|
|
竞价响应实现示例参见附录 C。
5.3.2.1 竞价响应对象的定义
竞价响应对象的定义见表16。
表16 竞价响应对象的定义
|
|
|
|
|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
5.3.2.2 广告对象的定义
广告对象的定义见表17。
表17 广告对象的定义
|
|
|
|
|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
GB/T 34941—2017
表17 (续)
|
|
|
|
|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
点击链接对象的定义见表18。
表18 点击链接对象的定义
|
|
|
|
|---|---|---|---|
|
|
|
|
|
|
|
|
GB/T 34941—2017
5.3.4.1 竞价响应错误
当出现以下情况，广告交易平台将竞价响应视为错误：
a) 规定的时间内无响应；
b) 无法解析 Bid Response 对象，包括 protobuf编码错误和必选项缺失；
c) 竞价请求的 ID 与竞价返回的 ID 不匹配；
d) 竞价请求中无与竞价返回中的广告ID 相匹配的ID;
e) 广告落地页面为非法网址或者非最终网址(如访问后会跳转到其他网址);
f) 广告点击链接为非法网址；
g) 竞价返回中返回的货币与竞价请求里设定的货币不同；
h) 广告片段与广告位类型不匹配，如对图文广告位返回VAST 代码；
i) 在竞价返回中同时填写或者同时不填写动态创意和静态创意部分；
j) 广告静态创意地址为非法网址或者指向广告位所不支持的文件格式；
k) 创意的宽度或高度填写了零。
5.3.4.2 竞价响应被过滤
在竞价响应填写正确的前提下，Ad Exchange将因如下原因过滤竞价响应：
a) 媒体限制特定创意属性的广告的展现；
b) 媒体限制敏感类别的广告内容的展现；
c) 媒体限制着陆页地址为某些网址的广告的展现；
d) 媒体限制指定广告主的广告的展现(如该广告主在销售保护名单之列);
e) 广告返回的价格低于竞价请求里设定的底价。
对于竞价成功的竞价方，广告交易平台会发出胜出通知。协议为 HTTP GET。
胜出通知的 URL
和形式由竞价方定义。 一定量的替换宏可以插入在胜出通知的 URL
中。在发出胜出通知前，广告交
易平台会对制定的宏进行查找和替换。
与广告胜出通知相关的宏同样可以置于广告标记中，广告交易平台会将同样的数据替换作为胜出
通知地址。如果竞价方希望从自身设备收到胜出通知，那么可以在广告标记中包含一个追踪像素地址，
地址中包含可用的宏。
可用宏说明见表19。
表19 可用宏说明
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
GB/T 34941—2017
替换前，宏数据值出于安全考虑，宜用多种混淆算法或加密算法来编码。编码方式可由广告交易平
台和竞价方确定。
宏数据应慎重使用。对于广告交易平台和出价方之间的通信不必编码，但是对于通过媒体使用广
告标记里的追踪像素来传送到设备浏览器而产生的宏，宜进行编码。
竞价失败的反馈一般在非实时部分，应通过非实时流程将数据回传给竞价方。
当 Ad Exchange和 DSP
跟踪点击情况时，宜在点击地址中采用点击宏。点击宏说明见表20。
表20 点击宏说明
|
|
|---|---|
|
|
|
|
在广告胜出通知中，交易平台需要将获胜价格通过价格宏%%WIN PRICE%%
发送给赢得竞价
的第三方。
由于该信息为重要数据，如果是在媒体端通过追踪像素来回传的话，建议使用加密算法。加密解密
算法由交易平台和竞价方确认和实现。
价格单位由 Ad Exchange 和 DSP 确认。
加密算法可以采用基于SHA-1 HMAC算法进行加密，例C++ 模块，可以直接用
openssl 中的接
口实现。竞价方在注册时获得32字节的加密秘钥，用于解密；获取32字节的完整性检测密钥，用于价
GB/T 34941—2017
格完整性检查。
参考加密格式如下：
初始化向量(16 bytes)}{加密的价格(8 bytes)}{完整性签名(4 bytes)}
加密价格的长度固定为28个字节，其中包含16个字节的初始化矢量、8个字节的密文以及4个字
节的完整性签名。
示例 ：使用基于 SHA- 1 HMAC 算法的加密解密。
加密阶段伪代码：
pad = hmac(e key,iv)//取前8个字节
enc price =pad\<xor)price
signature = hmac(i key,price l\| iv) //取前4个字节
final message = WebSafeBase64Encode(iv II enc price \|I signature)
解密阶段伪代码：
(iv \|\| enc price \|\| signature)= WebSafeBase64Decode(final message)
pad = hmac(e key,iv)
price = enc price(xor)pad
conf sig = hmac(i key,price l\| iv)
success =(conf sig ==signature)
字符与表达式解释见表21。
表 2 1 字符与表达式说明
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
%%EXT DATA%%,
竞价方提供的扩展参数，用于竞价方自定义内容。竞价方可以在提前上传
的胜出通知地址或者点击监测地址中使用自定义宏，然后在实时竞价时填充相关字段，交易平台会将之
前 设 置 了 % %EXT DATA%% 宏的地方用字段中的数据替换。
例如，竞价方在点击监测地址中使用了自定义宏：http://click.adserver.com?
some param&.click
url=clkurl&.ext=%%EXT DATA%%,
那么在实时竞价时，如果竞价方传递了替换宏的数据， 如 ext data = some
param,那么在投放广告时，上述代码会被替换，变为
http://click.adserver.com?
some param&.click url=clkurl&ext=some param。
标识符映射(即"ID
映射")是指将不同域/不同设备中的受众建立映射关系，以便在各种系统中能
识别出对方传递过来的受众 ID, 对各方信息进行整合。 ID
映射结果不会识别用户的身份信息，与受众
在现实生活中的身份信息无关。
GB/T 34941—2017
在 ID 映射中，Ad Exchange会在竞价请求中将 DSP 的受众 ID 和此 ID
对应的用户信息一同传给 DSP, 作为 DSP 竞价的依据。 DSP
可以自己存储上面所讲的映射表，也可以托管给 Ad Exchange来代
为存储。
5.5.2.1 准备
首先，DSP 需要向 Ad Exchange 申请自己的DSP ID,此 DSP ID应出现在每个ID
映射请求中。之
后，DSP 需要向 Ad Exchange 注册一个重定向URL,Ad Exchange 的 ID
映射服务器会将映射的返回
结果、非 Ad Exchange的额外URL 参数等信息拼接到重定向 URL
后，通过302重定向给 DSP 的 ID
映射服务器。
5.5.2.2 匹 配
DSP 或者Ad Exchange在每个需要匹配的流量上植入 ID 映射代码。在每个需要 ID
映射的广告 展现上，用户的浏览器都将访问 Ad Exchange 的 ID 映射服务器
URL, 完成一次完整的 ID 映射流程。 建议将 ID 的生存周期为14
d,在生存周期内的ID,不需要重复的进行 ID 映射。下面将详细描述一个
完整的匹配流程，见图5所示。
style="width:9.75347in;height:5.93333in" />
图 5 ID 映射流程
图5所示的 ID 映射的详细过程如下：
a) 用户打开浏览器，见图5中的①;
b) 浏览器向 Ad Exchange 的 ID 映射服务器发起请求，见图5中的②;
c) Ad Exchange 的 ID 映射服务器查找 exchange id,并重定向到 DSP 的 ID
映射服务器，见图5 中的③;
d) DSP 的 ID 映射服务器接收到 exchange id,建立 DSP 的 user id 与
exchange id 的映射关系 (如果DSP 不需要 Ad
Exchange托管映射表，则直接返回1*1像素图片给用户即可),见图5 中的④;
e) DSP 的 ID 映射服务器查找DSP user id,并重定向到 Ad Exchange的 ID
映射服务器，见图5 中的⑤;
GB/T 34941—2017
f) Ad Exchange的 ID 映射服务器接收到 DSP 的 user id,建立 exchange id
与DSP 的 user id 的 映射关系，见图5中的⑥;
g) Ad Exchange 的 ID
映射服务器返回空白1*1像素图片给用户，见图5中的⑦。 参数设置见表22。
表22 参数说明
|
|
|
|
|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
本标准对竞价过程中的核心信息字段进行了定义，对于各家 Ad
Exchange独有的特性字段应在接 口中利用Protobuf 的
extensions特性在其设定的字段编号中定义，命名规则需参考本标准中相同命名
风格。
程序化营销执行过程划分为执行前准备、执行中数据测量、执行后结算三个阶段。如图6所示。
style="width:11.87993in;height:1.02674in" />执行中数拆测量
图 6 程序化营销执行过程
程序化营销执行各阶段的工作内容如下：
a) 执行前准备工作包括：广告主资质审核、广告素材审核、第三方监测认证；
b) 执行中数据测量工作包括：程序化广告曝光测量和广告点击测量；
c) 执行后结算工作包括：结算标准及数据差异核对方法。
程序化营销技术平台(包括 DSP、SSP 或 Ad
Exchange)应依据国家法律法规及相关部门行政管理
GB/T 34941—2017
的规定对广告主资质进行审核，包括但不限于《中华人民共和国广告法》《互联网广告管理暂行办法》及
各行业法律、行政法规等。如所遵循的法律、行政法规有修改，本标准应按照最新的法律、行政法规
执行。
程序化营销技术平台(包括 DSP、SSP 或 Ad
Exchange)应依据国家法律法规及相关部门行政管理
的规定对广告内容进行审核，包括但不限于《中华人民共和国广告法》《互联网广告管理暂行办法》及各
行业法律、行政法规等。同时本标准对广告物料技术审核也做出要求，详见表23。
表23 广告物料技术审核要求
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
第三方监测认证分为公司资质认证和监测能力认证：
GB/T 34941—2017
a)
公司资质认证：第三方监测公司应提供税务登记证复印件；公司营业执照复印件；法人代表身
份证复印件等资料给 Ad Exchange 备案审核，提交资料需要清晰、齐全。
b) 监测能力宜认证以下方面：
1) 用户信息隐私保护认证：需第三方提供证明和保护方法；
2) 监测方法认证：需第三方提供不同监测方法说明及示例；
3) 数据准确性认证：广告展现、点击数据测试对比，第三方监测公司与 Ad
exchange 误差应 小于10%;
4) 反作弊方法认证：反作弊方法，反作弊涉及指标及结果；
5) 监测响应时间认证：服务器数量、机房位置、响应时间、QPS。
程序化营销数据测量是指程序化广告投放执行过程中，Ad Exhange 和 DSP
对于投放数据的统计
方法，包括广告投放的曝光和点击的测量。广告投放的曝光数据将作为DSP 和 Ad
Exchange投放结算
的依据，所以需要统一的数据统计规则，并确定出现数据差异的核查和处理原则。
程序化广告曝光测量流程如图7所示。
|
|---|
style="width:9.42663in;height:6.86664in" />用户 媒体 Ad F.xchange DSP
第三方监测平台
广告展示请求
(1)
请求广告 (2)
广告展现 (5)
竞价成功 (Win (6)
Ad Exchange计数、 (8)
向DSP 广播
(3)
DSP 竞价
(4)
Notice)
第三方曝光代码
(7)
图 7 程序化广告曝光测量流程
图7所示的程序化广告曝光测量流程详细说明如下：
a) 用户向括页面或应用发起广告展示的请求，见图7中(1);
b) 广告位代码向 Ad Exchange服务器发起广告请求，见图7中(2);
style="height:1.1in" />class="anchor">GB/T 34941—2017
c) Ad Exchange 向 DSP 广播，告知 DSP 广告展示机会，见图7中(3);
d) DSP 在规定时间内出价竞标，见图7中(4);
e) Ad Exchange根据竞价规则，展示竞标成功的DSP 的广告，见图7中(5);
f) 展示广告的同时，通知DSP
赢得了竞价，并附带赢得竞价的价格，见图7中(6);
g) 展示广告的同时，通知第三方监测平台，见图7中(7);
h) 通知 Ad Exchange成功展示广告，见图7中(8)。
图7展示了一般曝光测量方法及步骤，其中有些步骤可以省略，如果没有第三方监测，则不需要步骤
g)。
本标准列举了两种点击测量流程规范。串行点击测量方法指的是 Ad Exchange
和 DSP 以及第三 方测量平台是采用先后执行顺序串联起来执行，即先执行 Ad
Exchange 的计数，再由 Ad Exchange 重 定向到 DSP,DSP
记录数据后再重定向到第三方监测平台或直接重定向到广告主页面。并行加串行点
击测量方式指的是用户发生点击时，同时向Ad Exchange 和 DSP
提交点击数据，Ad Exchange 和 DSP
分别计数，互不影响，有第三方监测时，由 DSP
方串行重定向到第三方监测平台，最后再重定向到广告 主页面。
采用并行加串行点击测量方式，因通常 Ad Exchange和 DSP
的数据差异较小，故宜采用此种测量 方式。
串行点击测量流程如图8所示。
style="width:11.77292in;height:1.04676in" />串行点击测量流程
style="width:11.22668in;height:8.66008in" />用户 媒体 Ad Exchange
DSP 第三方监测平台 广告主
点击广告
(1)
点击数擦上报
(2)
[
\< 302重定向—
点出数据上报
(3)
302重定向
点击数据上报
(4)
302重定向
1
I
打开新窗口展示广告页面
(5)
图 8 串行点击测量流程图
GB/T 34941—2017
图8所示的串行点击测量流程说明如下：
a) 用户点击广告，见图8中(1);
b) 点击数据提交到 Ad Exchange,记录点击，并重定向到DSP
服务器，见图8中(2);
c) DSP 收到点击数据，记录，并重定向到第三方点击监测，见图8中(3);
d) 第三方点击监测收到数据，记录，重定向到广告主页面，见图8中(4);
e) 在新窗口打开广告主页面，见图8中(5)。
并行加串行点击测量流程图如图9所示。
style="width:11.52014in;height:1.10694in" />
style="width:10.92014in;height:8.68681in" />
图 9 并行加串行点击测量流程图
图9所示的并行加串行点击测量流程说明如下：
a) 用户点击广告， 一次点击产生两个事件，即同时将数据提交到Ad
Exchange和DSP, 见图9中(1);
b) 点击数据提交到Ad Exchange,记录点击数据，见图9中(2);
c) 点击数据提交到 DSP,
记录点击数据，并重定向到第三方监测平台，见图9中(3);
d) 第三方监测平台收到数据，记录，重定向到广告主页面，见图9中(4);
e) 在新窗口打开广告主页面，见图9中(5)。
在程序化RTB 交易中，Ad Exchange和 DSP
的计费标准以千次广告曝光为结算单位，双方结算采
GB/T 34941—2017
用广告曝光的定义，建议以Ad Exchange统计的曝光数据为准。
由于网络环境，Ad Exchange和 DSP
双方机房条件等的不同，计费数据会出现不等的差异，正常数
据误差范围由双方合同自行约定，建议为5%。
Ad Exchange和 DSP 数据误差如果超过双方约定的范围，
一方或双方对数据差异有异议，可请求
对方提供广告投放日志进行数据核对。
日志最少字段包括：时间、素材 ID、竞价请求 ID、IP。 其中，竞价请求 ID
是 Ad Exchange 每次发起
请求时的唯一标识，全局唯一。
各方(包括 DSP 和第三方)都应记录 ID
以便统一排除问题。日志保存时间建议为结算后90 d。
程序化营销数据是指专门服务于程序化营销服务的输出数据与应用型数据。程序化营销数据是
Ad Exchange、DSP、SSP、DMP 等技术平台整合运转的核心。
程序化营销数据的来源主要是第一或第三方采集的网页浏览行为数据、社交行为数据、电商购买行
为数据、搜索行为数据等。不同来源的杂乱数据通过整合、结构化处理、合并归一处理，变为可以用程序
化营销系统实时调用的有业务含义的数据。
由于程序化营销业务需求的特殊性，遵从行业适用性原则，可以从客户、用户、媒体三个维度对程序
化营销数据进行标准化分类。
程序化营销数据分为三种类型，包括：
a)
用户数据：与用户身份或活动相关的数据，包括可用于识别出用户身份的个人信息，以及反映
用户网络活动的行为数据；
b) 媒体数据：数字化媒体类型与媒体所属行业类型数据；
c) 客户数据：广告主所属行业与旗下商品品类。
程序化营销数据主要来源于 PC
互联网和移动互联网媒体，包括网页浏览点击数据、购物交易数
据、搜索数据、电信运营商数据等。
对网民上网行为数据的采集方法主要有以下几种：
a)
针对普通互联网或移动互联网网站，采用页面嵌码的方式，利用浏览器储存在用户本地终端上
的数据(cookies),服务器对网民访问网页的行为进行记录浏览 URL、
浏览时间、地域、访问来
源等，通过对网页内容解析，将网民进行结构化分类；
b) 针对移动设备的 APP 终端，在 APP 应用端嵌入 SDK
(软件开发工具包)代码进行数据采集， 数据采集内容的范围则取决于APP
端对其数据的开放程度；
c)
针对购物交易数据，多数可采用企业自有数据。企业自有数据主要记录网民在企业自有平台
GB/T 34941—2017
的注册信息、浏览页面信息、购买交易信息等；
d) 针对网民搜索数据，可主要记录网民搜索关键词、句。
数据的采集和使用应遵循基本的准则如下：
a)
个人信息的采集应合法和公开透明，不应对个人财产造成伤害，保证用户有知情权或者征得用
户同意；
b)
采集的网民用户数据，应告知网民为什么采集信息，以及数据应用场景。数据实际应用目的应
与数据采集时所明确的目的一致。
用户数据，即与用户身份或活动相关的数据， 一般包括：
a)
用户个人信息：指相关系统在提供服务的过程中采集的，能够单独或者与其他信息结合标识用
户的信息，包括用户姓名、出生日期、身份证件号码、住址等身份信息以及用户使用服务的号
码、账号、时间、地点等日志信息；
b)
用户各种网络行为产生的数据：指用户在网络上的浏览、点击、搜索、网购等行为产生的数据，
能够表现出用户的兴趣、关注点、购买需求等特征。
用户数据主要来源于线上、线下用户行为数据，包括相关系统的 CRM
系统数据、ERP 系统数据，各
种搜索、移动、社交等媒体，以及网络分析工具、普查数据以及离线数据等来源。
对用户数据进行分类能够更好的对数据进行整合、分析以及应用，但是用户数据是海量而且复杂
的，为了使海量的数据能够被准确、及时的检索到并获得有效的一致性标识。用户数据分类应遵循的原
则如下：
a) 可识别性：指在不同的分类之间，在概念上可清楚地加以区分；
b) 便捷性：指用户数据可以容易地被分到某一类别中；
c) 独立性：指不同类别之间的数据是相互独立、没有交叉关系的；
d) 穷尽性：指分类能够覆盖所有用户数据；
e) 无歧义：指分类能够正确表现每类数据的特征，无二义性。
根据用户各种网络行为的特性、目前的实践以及细分原则(尤其是可识别性),可从基础信息和兴趣
意向两个维度对用户数据进行分类。
用户数据分类框架如图10所示。
GB/T 34941—2017
style="width:10.22708in;height:6.03403in" />
图10 用户数据分类框架
用户数据分类说明如下：
a)
基础信息：即用户的个人基本信息及用户在网络上表现出来的行为习惯数据，从人口学属性、
地域属性、财产属性以及在线习惯四个方面对用户进行描述。例如用户的姓名、年龄、职业、收
入、在网络上的注册信息以及上网时长、上网时段、与广告互动频率等描述信息。
b)
兴趣意图：能够表现出用户的长期需求、表达出用户的个人兴趣以及购买意图的数据，包括：
1)
关注话题：用户经常关注的领域、行业或者产品等数据，能够表达用户的长期需求，例如能
够表达出用户是车迷、喜爱美食、追求时尚、喜欢奢侈品等的数据；
2)
个人兴趣：表达出用户兴趣点的数据，例如用户喜欢数码产品，喜欢旅游等兴趣的数据；
3)
购买意向：能够表现出用户短期需求、有购买意图的数据，例如看相关商品评测、将商品加
入购物车等行为的数据。
由于用户数据应用场景多样，极具个性化，故本标准中的用户数据分类方法仅供行业各方参考，不
作为贯彻标准的要求。用户数据的详细分类示例参见附录B。
用户数据分类可应用于表6中的参数 user category的取值。
本标准中的媒体是指互联网媒体，媒体行业是指互联网媒体刊出的内容所属行业分类，如新闻、体
育、汽车、科技、旅游等。
媒体行业分类应遵循的原则如下：
a)
可区分性：基于行业共识，在不同的媒体行业与类型之间，类的概念可清晰区分；
b)
通用性：指媒体数据分类要适用目前主流的媒体分类，各类间不重叠，不冲突。
根据媒体数据分类原则，对媒体行业进行划分，详见表24。
GB/T 34941—2017
表24 媒体行业分类
|
|
|
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
GB/T 34941—2017
表24 (续)
|
|
|
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
媒体行业分类可应用于表9中的参数 page category和 site category的取值。
客户是指对通过程序化营销方式投放广告的企业单位，客户行业是对这些企业单位按其生产产品
或提供服务的特征作出的分类。国家建立了国民经济行业分类并对各行业进行编码，但不是所有的行
业都会广泛参与营销环节，因此，本标准重点关注营销领域活跃的客户行业。
数字营销中对客户数据进行合理划分主要目的是为了有效的利用客户的行业和商品数据，提高营
销的效率。客户数据的划分应遵循原则如下：
a) 可区分性：即各个分类之间可以清晰的区分，无交叉；
b) 规模性：即该分类在数字营销领域达到一定的市场预算规模。
依据客户行业定义和分类原则，对客户行业进行划分，见表25。
表 2 5 客户行业分类
|
|
|
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
GB/T 34941—2017
表 2 5 ( 续)
|
|
|
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
客户数据分类可应用于表5中的参数 excluded product category
以及表17中的参数 category 的
取值。
程序化营销的数据，可以应用在数字营销的各个场景。程序化营销模式流程如图11所示。
图11阐述了下面的数据应用场景：
当一个用户访问一个带有广告的页面时，DSP
实时对这次广告被展现的用户及媒体进行观察分
析，识别是否是目标受众、媒体环境是否安全，通过数据预估投放表现，从而判断是否进行广告投放并合
理的出价。
在 DSP
系统中，客户或代理公司可以借助数据自定义用户细分，对广告进行精准的投放或展现不
同的创意，或通过数据观察选择购买的媒体。
对 SSP
系统中，媒体可以清晰了解网站的用户，从而优化媒体内容，实现对不同用户的定制化内容
推荐，增加对用户吸引力。
GB/T 34941—2017
style="width:8.61337in;height:5.74002in" />SSP
AD EXCHANGE
SSP
2
SSP
N
DSP
1
图 1 1 程序化营销模式流程图
7.7.2.1 数据安全的含义
数据处理过程可分为5个主要环节：
a) 采集：指获取并记录数据；
b)
加工：指对数据进行的操作，如录入、存储、修改、标注、比对、挖掘、屏蔽等；
c)
应用：指将数据应用于系统提供的服务，如根据用户数据投放广告、根据媒体数据挑选优质流
量等；
d)
转移：指将数据提供给数据需求方的行为，如向公众公开、向特定群体披露、由于委托他人加工
而将数据复制到其他系统等；
e) 删除：指使数据在相关系统中不再可用。
数据处理过程中存在着诸多数据安全问题，包括数据的泄露、丢失、损坏、篡改、不当使用，可能会带
来损害数据主体(用户、媒体和广告主)切身利益、危害社会秩序等不良影响。为了保护互联网用户、媒
体、广告主的合法权益，维护网络信息安全，相关系统对其在提供服务过程中处理的数据的安全负责，保
护数据主体的隐私。对数据的保护贯穿于数据处理的所有环节中。
7.7.2.2 数据处理原则
在对数据进行处理时，应遵循以下基本原则：
a)
目的明确：处理数据应具有特定、明确、合理的目的，不扩大使用范围，不在数据主体不知情的
情况下改变处理数据的目的；
b)
最少够用：只处理与处理目的有关的最少数据，达到处理目的后，在最短时间内停止使用或者
删除能够识别用户身份的相关隐私数据甚至全部数据；
c)
公开告知：对数据主体要尽到告知、说明和警示的义务，以明确、易懂和适宜的方式如实向数据
主体告知处理数据的目的、数据的采集和使用范围、数据保护措施等信息；
d) 个人同意：处理个人信息前要征得个人信息主体的同意；
e) 质量保证：保证处理过程中的数据保密、完整、可用，并及时更新数据；
GB/T 34941—2017
f)
安全保障：采取适当的、与数据遭受损害的可能性和严重性相适应的管理措施和技术手段，保
护数据安全，防止未经授权的检索、披露及丢失、泄露、损毁和篡改数据；
g)
诚信履行：按照采集时的承诺，或基于法定事由处理数据，在达到既定目的后不再继续处理
数据；
h)
责任明确：明确数据处理过程中的责任，采取相应的措施落实相关责任，并对数据处理过程进
行记录以便于追溯。
除了遵循以上原则，在程序化营销过程中，应当严格遵守国家在信息安全方面制定的相关规定。
7.7.2.3 数据安全技术
在实施互联网用户个人信息保护时，可以采取一些技术方案。例如：
a) 在跨网络传输用户个人信息时，使用安全版协议，包括安全的
https(超文本传送协议)、SFTP (安全文件传输协议)、SSL 等；
b) 不直接存储用户个人敏感信息，先对个人敏感信息进行加密后再存储；
c) 对存储用户个人信息的物理环境采取隔离、安装防毒软件等保护措施；
d)
与外部数据源进行对接时，不直接使用可识别用户身份的用户数据作为标识，可以使用随机生
成的没有任何物理意义的编号作为标识。
7.7.3.1 概述
在处理用户数据时，相关系统需要得到数据主体的授权，包括数据拥有权和数据使用权。
7.7.3.2 数据拥有权
数据拥有权，即在采集数据之前相关系统需要征得数据主体的同意，包括默许同意或明示同意，使
相关系统具有拥有数据的权利。具体说明如下：
a)
采集非隐私、可公开的数据，可认为数据主体默许同意，如果数据主体明确反对，应停止采集或
删除数据；采集数据主体敏感、不可公开的数据时，应得到数据主体的明示同意；
b)
为了达到保护用户数据安全的目的，相关系统只采集能够达到已告知目的的最少信息，而且应
采用已告知的手段和方式直接向数据主体采集，不采取隐蔽手段或以间接方式采集用户数据；
c)
持续采集数据时需要提供相关功能，允许数据主体配置、调整、关闭数据采集功能；
d)
同时，相关系统不能直接向未满16周岁的未成年人等限制民事行为能力或无行为能力人采集
隐私数据，确定需要采集隐私数据的，应征得其法定监护人的明确同意。
7.7.3.3 数据使用权
数据使用权，是相关系统拥有数据之后需要得到数据主体授予使用数据的权利，主要涉及数据处理
的应用和转移环节，具体说明如下：
a)
相关系统不应违背采集阶段已告知的应用和转移目的，或超出告知范围和转移范围对用户数
据进行使用，而且应采用已告知的方法和手段进行使用；
b)
应保护用户数据主体的个人信息隐私，保证使用过程中数据不被任何与处理目的无关的个人、
组织和机构获知。
未经数据主体明确同意，不应向其他个人、组织和机构披露其处理的数据，应符合法律法规的其他
明确规定。
GB/T 34941—2017
(资料性附录)
竞价请求协议示例
竞价请求协议的C 语言实现示例如下。
|
|---|
GB/T 34941—2017
|
|---|
GB/T 34941—2017
|
|---|
GB/T 34941—2017
//对于苹果应用，该ID为移动应用的iTunes ID;对于安卓应用，该ID为应用的package
|
|---|
GB/T 34941—2017
|
|---|
GB/T 34941—2017
(资料性附录)
用户数据详细分类示例
用户数据按基础信息和兴趣意向两个维度进行分类(见7.4.1),将这两个维度作为一级类目。
一级
类目下设有二级和三级类目，三级类目下对应若干属性值。表 B.1
给出了用户数据的详细分类情况。
表 B.1 用户数据的分类表
|
|
|
|
|---|---|---|---|
|
|
|
|
|
|||
|
|
||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|
||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|
||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|
||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
GB/T 34941—2017
表 B.1 ( 续 )
|
|
|
|
|---|---|---|---|
|
|
|
|
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|
||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|
||
| 0.5 h左右 | |||
|
|||
| 2 h左右 | |||
| 3 h左右 | |||
| 4 h及以上 | |||
|
|
||
|
|||
|
|||
|
|||
|
|
||
|
|||
|
|||
|
|
|
|
|
|||
|
|||
|
|||
|
GB/T 34941—2017
表 B.1 ( 续 )
|
|
|
|
|
|---|---|---|---|---|
|
|
|
|
|
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
|
||
|
 |
|||
|
||||
|
||||
|
||||
|
||||
|
|
|||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
|
|
|
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
|||
|
||||
|
||||
|
||||
|
||||
|
||||
GB/T 34941—2017
表 B.1 ( 续 )
|
|
|
|
|---|---|---|---|
|
|
|
|
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|
||
|
|||
|
|||
|
|||
|
|||
|
|
||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|
||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|
||
|
|||
|
|||
|
|||
|
|||
|
GB/T 34941—2017
表 B.1 ( 续 )
|
|
|
|
|---|---|---|---|
|
|
|
|
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|
||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|
||
|
|||
|
|||
|
|
|
|
|
|||
|
|||
|
|||
|
|||
|
|
||
|
|||
|
|||
|
|||
|
GB/T 34941—2017
表 B.1 ( 续 )
|
|
|
|
|---|---|---|---|
|
|
|
|
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|
||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|
||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|
||
|
|||
|
|||
|
|||
|
GB/T 34941—2017
表 B.1 ( 续 )
|
|
|
|
|---|---|---|---|
|
|
|
|
|
|||
|
|||
|
|
||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|
||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|
||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|
||
|
|||
|
GB/T 34941—2017
表 B.1 ( 续 )
|
|
|
|
|---|---|---|---|
|
|
|
|
|
|||
|
|
||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|
||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|
||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
GB/T 34941—2017
表 B.1 ( 续 )
|
|
|
|
|---|---|---|---|
|
|
|
|
|
|||
|
|||
|
|||
|
|
||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|
||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|
||
|
|||
|
|||
|
|||
|
|
||
|
|||
|
|||
|
|||
|
|||
|
|
|
|
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
GB/T 34941—2017
表 B.1 ( 续 )
|
|
|
|
|---|---|---|---|
|
|
|
|
|
|||
|
|||
|
|
||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|
||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|
||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|
||
|
GB/T 34941—2017
表 B.1 ( 续 )
|
|
|
|
|
|---|---|---|---|---|
|
|
|
 |
|
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
|||
|
||||
|
||||
GB/T 34941—2017
(资料性附录)
竞价响应协议示例
竞价响应协议的C++ 语言实现示例如下。
|
|---|
GB/T 34941—2017
|
|---|
更多内容 可以 GB-T 34941-2017 信息技术服务 数字化营销服务 程序化营销技术要求. 进一步学习